1. Field of the Invention
This invention relates generally to the field for software design; and, more particularly, to distributed application in an application environment for supporting portable, embedded, concurrent, and/or real-time applications.
2. Description of the Related Art
The term xe2x80x9capplicationxe2x80x9d is commonly used to refer to the objective or problem for which the software, or xe2x80x9capplication program,xe2x80x9d is a solution. The form of the solutionxe2x80x94the application programxe2x80x94is dependent, in part, on the configuration of the hardware on which the software is executed and, in part, on the other programs that may be executing in concert with the application program.
An application program is typically translated from an instruction set derived from one of several well-known programming languages to an instruction set closely reflecting the capabilities of processor executing the application program. This translation is accomplished by programs generally know as xe2x80x9ccompilers,xe2x80x9d xe2x80x9cassemblersxe2x80x9d or xe2x80x9cinterpreters.xe2x80x9d These programs translate the application program""s original instructions to a set of instruction typically know as xe2x80x9cmachine codexe2x80x9d for which there is a one-to-one correspondence between machine code instructions and the unitary operations the machine (or processor) is able to perform. Typically, machine code instructions are dependent on the machine""s central processing unit (or CPU). The operation of these and similar programs are well known to those of ordinary skill in the art.
Application programs are frequently executed simultaneously with other application programs, sharing (and sometimes competing for) the resources of the host hardware.
Application programs must also frequently share the resources of the host hardware with xe2x80x9cinterrupts service routinesxe2x80x9d (ISR). These ISRs are typically short program segments that interrupt the normal program instruction sequence and execute, substantially immediately, in response to a hardware signal (an xe2x80x9cinterruptxe2x80x9d) to the CPU.
Application programs may be invoked by, or may invoke, the services of other sets of programs running on the host that are collectively know as an xe2x80x9coperating system.xe2x80x9d Operating system programs are typically responsible for controlling the allocation of the host""s resources, including access to the host machine""s data stores, central processing unit, and input/output devices. One aspect of controlling the allocation of a host""s resources typically involves insuring that no two applications, ISRs, or portions of the same application try to control a resource at the same time. A number of techniques for preventing this are well know in the art, including semaphores, counting semaphores, mutexes, signals, and critical sections. A critical section is a portion of a program that, once started, is uninterruptible and executes continuously without allowing other programs to run until the critical section has ended.
Application software is executed within some xe2x80x9chost environment,xe2x80x9d defined collectively by the host machine""s hardware (including, possibly, application-specific support hardware such as an application-specific integrated circuit or xe2x80x9cASICxe2x80x9d) and operating system.
Commonly, commercial application software vendors are required to adapt, or xe2x80x9cport,xe2x80x9d their application programs to run in a multiple heterogeneous host environments. These environments may differ in their CPU""s, choice of operating systems, and application-specific hardware. In order to port an application program from one host environment to another, it is typically necessary to account for any or all of these differences.
The tradition approach to porting applications is to write the application program in a xe2x80x9chigh-level languagexe2x80x9d that hopefully can be recompiled to generate machine code that can run within any of the prospective processors. While this xe2x80x9ctraditional approachxe2x80x9d solves the portability problem at the machine code level, it is only partly addresses the application portability problem. It is also necessary to account for differences in the host environment""s operating system and application-specific support hardware. For example, each operating system defines a unique application programming interface (xe2x80x9cAPIxe2x80x9d) which application programs use to access the operating systems services. Because these APIs are unique, portions of the application program having access to the operating system""s API must be rewritten when the application program is ported to a new operating system. In addition, accounting differences in application-specific support hardware (circuits that are able to perform a portions of the application""s function that otherwise have to be performed in software) also may require that some portion of the application software be rewritten.
A problem with the traditional porting method is that this method requires that at least some portion of the application program be rewritten. This is a potentially costly and error-prone process. Because there is a likelihood of introducing unintentional errors whenever the application program is altered, this method mandates that the application developer bare the additional expense of re-testing the application after the indicated changes are complete.
More significantly, and despite the availability of a number of commercially operating systems, most embedded applications are deployed today are in host environments that supply no operating system services. Thus, for application portability, a means must be provided to ensure application software can operate correctly isolated from the vagaries of its host environment.
Distributed applications in a portable thread environment are disclosed. In one embodiment, a method comprises receiving a message from a first PTE at a second PTE, wherein the message contains a destination address; determining if the message is intended for the second PTE using the PTE destination address; routing the message to a third PTE if the message is not intended for the second PTE; and executing threads associated with the message in the second PTE if the message is intended for the second PTE.